As 3rd generation (3G) mobile systems continue to evolve, there is a growing market interest to support high bit-rate multi-media services. At the same time, 3G operators face a strong competition from non-conventional business models employing, for instance, IEEE 802.X based technologies that provide wireless access to Internet Protocol (IP) based multimedia services (IMS) or to the Internet.
Therefore, mobile operators are interested in augmenting their evolving radio access networks (RAN) with a technology that provides them with the ability to offer broadband IP based services, including TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) based applications. In this document we will collectively refer to these high bit rate RAN:s beyond the existing 3G radio access technologies as “4G RAN”:s. Following documents are determined as close prior art:    [1] WINNER Project, “Description of identified new relay based radio network deployment concepts and first assessment by comparison against benchmarks of well known deployment concepts using enhanced radio interface technologies”, IST-2003-507581 D3.1    [2] C. Barakat, P. Thiran, G. Iannaccone, C. Diot, P. Owezarsid, “A Flow based model for Internet backbone traffic”, http://www.imconf.net/imw-2002/imw2002-papers/123.pdf    [3] CISCO Document, Configuring QoS, http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12—2—25/conf/qos.pdf
A key observation is that 4G can advantageously be designed exclusively for IP-based applications. That is, we can assume that the 4G RAN only interfaces to the cellular operator's packet switched domain and all applications running over 4G are IP based. It follows that it further can be assumed that all applications are rate adaptive, including TCP applications and also many of the UDP applications, including VoIP (Voice-over-IP) applications employing rate adaptive coders.
A number of features have been listed for 4G RAN:                Exclusive Focus on IP-Based and Rate-Adaptive Applications        Only One Shared Traffic Channel per Cell        Instant Access to all of the Currently Available Bandwidth        No Support for Session-Based Admission Control & Resource Reservation (Single Bearer Concept)        No Distinction Between Real-Time, Quasi-Real-Time, and Non-Real-Time Applications        Lossless HARQ (Hybrid Automatic Repeat Request) with Bounded Retransmission Delays per IP Packet        Congestion Control Based Purely on End-to-End Mechanism (Flow-Class Queueing and Active Queue Management)        4G RAN Provides Per-Hop QoS (a la DiffServ) Through Different Service Classes        Policy-Based Scheduling Between Service Classes        
A key requirement on 4G systems is that the system complexity must be kept as low as possible. This applies particularly to Quality of Service (QoS) mechanisms that aim to provide some basic level of service differentiation as well as to ensure system stability at congestion conditions.
The Internet does not provide any end-to-end QoS and, of different reasons, is unlikely to ever do so. The per-hop model of Differentiated Services (DiffServ, DS) is an attractive mechanism to provide QoS between edge nodes of a network, and therefore it is well suited for the purpose of providing QoS in a 4G RAN. DiffServ (according to the standard documentation IETF RFC2475) has been partly successful in the Internet where it is mainly implemented within the domain of one operator. DiffServ uses the 6-bit DSfield in the IP header to mark the service class of an IP packet. A big advantage with this approach is that IPsec (IP security mechanism) does not encrypt the DS field. IPsec is increasingly used, e.g., for corporate access. Therefore, the 4G RAN is envisaged to implement to provide different service classes. The service class of an IP packet is marked in the DS field. It is a 4G operator's freedom to decide how many service classes to be supported.
Hence, the term Quality of Service (QoS) is defined as: “A network is said to support QoS if it is able to offer different and differentiable levels of service Quality over a shared infrastructure”.
With this definition of QoS, it should be noted that when the load on the network is low and all user terminals (UT) have sufficient coverage (sufficiently high receiver level) then there is no difference between the different service classes. In those situations the 4G RAN can transport data faster (without IP packet losses and sufficiently low delays) then the applications currently used by all UTs in a cell can deliver the data.
An important feature that 4G needs to support is a mechanism by which an operator can associate certain QoS levels with applications provided by the operator through its service network or by 3rd parties chosen by the operator. The services may be divided into “public” and “private” service classes. Public service classes are offered publicly and can be subscribed to by 4G users. The idea is that each UT belongs to exactly one public service class, e.g. one of “gold”, “silver” or “bronze”. The public service class gold could be tied to the user's subscription. Private service classes are not available to 4G users, but can only be set by a 4G operator. The idea is that packets that belong to an application chosen by the operator are assigned to a private service class, hereafter denoted as platinum. In that way a 4G operator can ensure that those packets get differentiated treatment in the 4G RAN, e.g. priority over packets of public service classes. With this approach it will be possible to emulate guaranteed bit rates that can be associated with a specific service chosen by the 4 G operator. This requires an appropriate network dimensioning and a corresponding policy for handling the different service classes (priorities, minimum bit rates, etc.).
Consider the QoS supporting system architecture of FIG. 2. As the overall traffic load in the system increases, the system's congestion level starts increasing and eventually only platinum user traffic can be served (due to the second level scheduling mechanism).
When the traffic load from platinum users alone reaches high load regions, there is a need to prioritize some platinum users. That is, there is a need for an algorithm that determines which platinum users to schedule over the radio interface when the system is congested to the extent that not all platinum traffic can be scheduled.
This problem is non-trivial because the system does not differentiate two users (two UT:s) that belong to the same priority class (e.g. platinum). As in FIG. 2, the second level scheduler may be associated with an interclass policy and it may also keep track of the age of outstanding IP packets. These pieces of information are however not sufficient, since these do not allow to distinguish between users of the same class (e.g. platinum) that have outstanding IP packets with the same age.
Shortly put, there is a need for an algorithm that determines which UT's sessions should not receive any scheduling resources at the MAC level in the case of congestion. This problem is referred to as the intra-class UT blocking problem.